Tokening, RenderCache, and Selectivity Make Software Claims Easier to Inspect
Tokening, RenderCache and Selectivity address different problems, yet their recent documentation shares a useful habit: it exposes the boundary between a claim and the evidence supporting it. Tokening shows what an agent is allowed to do. RenderCache distinguishes saved HTML from the response actually written by a server. Selectivity records which smaller inputs still meet a test. Reviewed on October 27, 2026, these projects offer concrete examples of how a small software product can make its behavior available for inspection before asking users to trust a broad promise.
Start with the Tokening WordPress demonstration. An agent receives permission to edit one post once. It succeeds on the allowed edit, then encounters refusals when it repeats the call, targets another post or attempts deletion. A fresh one-use grant is also tested with two parallel calls, producing one winner. The browser experience replays a recording from a throwaway WordPress installation. It does not operate the visitor’s website. That makes it accessible, while leaving a separate question for an operator: can the same constraints be reproduced in the environment where the gateway will actually run?
The explanation of task grants instead of API keys supplies the underlying mechanism. A job can bind the tool call to a record, permitted fields and a limited lifetime. The gateway retains the real service credential and checks the incoming operation. This changes the authority available to an agent during one task. Its usefulness depends on a deployment detail that is easy to overlook: the agent must not also possess a credential that lets it bypass the gateway. A carefully limited front door means little if another route carries the account’s broader permissions.
Tokening’s prompt injection discussion also describes a remaining failure. An attacker who persuades an agent to write unwanted text into an allowed field can still produce a call that fits the grant. Restricting which post may change does not establish that the new prose is correct. This is a meaningful limit, and it should remain attached to the product’s story. The demonstration supports a claim about enforcing a defined operation. It cannot turn an allowed operation into an editorial judgment.
RenderCache approaches evidence from the delivery side. Its request and rendering explanation describes a service that saves rendered responses for eligible crawler requests while ordinary visitors receive the original application. A fresh snapshot, an expired snapshot and a cold request have different behavior. A cold miss proxies the origin and queues rendering in the background, which can still expose a JavaScript shell on that first visit. Warm coverage therefore matters. Reading that detail is more informative than seeing a cache badge and assuming every crawler request receives a complete rendered page.
The response receipts article draws another important boundary. A HEAD request can use a saved response without delivering an HTML body. A conditional request may return 304, and a partial write may stop early. RenderCache records cache availability separately from full snapshot delivery. Even a complete server-side write does not prove that the remote client indexed the page or that an AI service cited it. User-agent strings are claims, too. The practical value is a narrower, more inspectable account of what happened at the server, rather than a promise about downstream search behavior.
Selectivity offers a different kind of inspection in its CSV importer case study. A deliberately faulty importer and a reference implementation disagree after a discount and a refund interact. In the documented generated example, a 123-line file becomes a three-line reproducer containing the header and the two relevant records. The reduction makes the interaction readable. The case also reports unresolved candidate checks and withholds the stronger local-minimality claim. That distinction matters: a small input that still demonstrates the disagreement and a proven deletion-minimal result are different outcomes.
The Selectivity playback lets readers follow candidate checks from recorded runs, with rejected candidates distinguished from the latest accepted input. It is a useful way to understand the procedure, provided the examples stay in context. Generated fixtures with known answers establish behavior under those conditions; they do not establish typical performance on someone else’s production defect. Reproducing the run with an appropriate predicate is the next test for a developer considering adoption.
These projects move quickly enough for demos and explanations to become useful entry points, but the stronger signal is their treatment of limits. Permission enforcement, response delivery and input reduction can each be examined without confusing them with a larger outcome. The decision value follows from that precision. A user can identify the property they need, inspect the example and ask what remains untested in their own environment. That is a sounder basis for trying a small tool than the confidence of its homepage.