This is exactly what you need.
The TypeBridge can be applied to a type and use multiple properties of that type.
You can access properties and combine them in the TypeBridge.write method. Then, in the same method, you can write the result of your computations to an index field.
You cannot manipulate the whole document, but you can add index fields whose content you fully define as JSON.
For Elasticsearch, you can declare index fields as “native”, giving you the ability to define their mapping as JSON directly and to write their value as JSON upon indexing. Documentation is coming in Beta3, but here is an example for Beta1/2. Just adapt the example to target types (annotation target, TypeBridge/TypeBinder instead of PropertyBridge/PropertyBinder) and to use the percolator index field type, and you should be good to go.
If you mean information that is completely transient and not stored in the database at all, such as a session ID from the HTTP request that changed the entity, then I wouldn’t recommend that at all: it would mean that, upon reindexing, that information would be lost.
If you mean information that is not stored “as is” in the database, but can be derived from the information stored in the database (a sum of two properties in the same entity, something like that), then yes you can totally do that. That’s the point of TypeBridges, actually. The example in the documentation concatenates the first and last name to index the full name, but you can do something more complicated. Just remember to declare the dependencies to the properties you use in your binder (context.getDependencies().use( ... )), otherwise Hibernate Search will sometimes “forget” to reindex your entity.
Note that in Beta3, APIs are going to change a little, but migration should be easy enough (a few lines of code).